An ever-increasing number of applications (i.e., computer software) with various features are available to users of personal computers. Users can tailor the operation of these applications to suit their needs by specifying various configuration parameters. For example, a browser application may have a configuration parameter that provides a URL of a web page that is displayed initially whenever the browser application starts (i.e., “a home page”). The browser application may also have configuration parameters that identify programs to be invoked to process certain types of content (e.g., a “jpeg” file) and that specify passwords to be used when the application connects to various servers. The values of the configuration parameters can be stored in application-specific configuration files such as UNIX resource files or in a central registry such as the Windows® registry file. The application-specific configuration file for an application may have an internal format that is specific to that application. The Windows® registry file organizes configuration parameters hierarchically with each configuration parameter having a path and optionally a value. The applications access these files to store and retrieve their configuration parameters.
If certain configuration parameters are incorrect, then the applications may exhibit an undesired behavior. For example, if the value of a home page configuration parameter is not set correctly, then when the browser application starts, it will exhibit an undesired behavior by not displaying a home page or displaying the wrong home page. If a configuration parameter incorrectly indicates a certain text editor should be invoked to process a graphics file, then the undesired behavior will be the incorrect display of the graphics content. Similarly, if a password configuration parameter has the wrong password, then the failure to connect to the server will be the undesired behavior.
Because of the complexity of applications and their large number of configuration parameters, it can be very time-consuming to troubleshoot which configuration parameters are at fault for causing an application to exhibit the undesired behavior. Most users of personal computers have difficulty performing this troubleshooting. As a result, users typically rely on technical support personnel to assist in the troubleshooting. This troubleshooting not only is expensive but also users may experience a significant productivity loss as a result of their inability to effectively use an application that is exhibiting an undesired behavior.
Typically, technical support personnel use an ad hoc approach to troubleshooting configuration problems. The personnel, using knowledge gained from experiencing similar problems, will try to narrow in on the at-fault configuration parameter. This ad hoc approach can take a considerable amount of time, especially if it is a combination of configuration parameters that are incorrect. In some cases, the technical support personnel may compare the configuration parameters to a set of “ideal” configuration parameters for that application. Because of the large number of configuration parameters available and the large number of possible values for each configuration parameter, many of the configuration parameters will have no “ideal” value. Thus, technical support personnel still need to review those configuration parameters of the application that are different from the set of ideal configuration parameters.
Technical support personnel, especially members of a product support services group that is supporting an application, may handle a large number of requests from users to help in troubleshooting problems of the application. When a request is received, the technical support personnel may generate a problem report that describes the problem or the symptom. When the problem is solved, the technical support personnel may close the problem report and add a description of the solution to the problem report. In many cases, the solution may be to change a configuration parameter.
A technique for troubleshooting configuration parameters has been proposed that uses “persistent-state checkpoints” to identify configuration parameters that have been modified since an application was last known to not exhibit the undesired behavior. Some operating systems can be configured to automatically create copies of configuration parameters (i.e., a checkpoint) at certain intervals. The technique may compare the current configuration parameters to the configuration parameters of a checkpoint taken when the application was known to not exhibit the undesired behavior to identify those that have been modified. This set of modified configuration parameters is referred to as a “difference set.” Since the number of configuration parameters in the difference set may be large, the technique generates a trace of the configuration parameters that are accessed when the application exhibits the undesired behavior. This set of accessed configuration parameters is referred to as a “trace set.” The technique intersects the difference set with the trace set to identify an “intersection set.” The technique may then rank the configuration parameters of the intersection set based on the relative order of their appearance in the trace set or based on an inverse document frequency calculation in which difference sets derived from consecutive checkpoints represent documents. Such a technique is described in the “Persistent-state Checkpoint Comparison for Troubleshooting Configuration Failures,” by Wang, Y., Verbowski, C., and Simon D., Proc. IEEE International Conference on Dependable Systems and Networks (DSN), June 2003, which is hereby incorporated by reference.
It would be desirable to provide an alternative technique, which does not rely on difference sets of consecutive checkpoints, for ranking configuration parameters that may be at fault for causing an application to exhibit an undesired behavior.